Repository navigation
feat: cierra los huecos de Java, C# y Angular en el kit - #17
Conversation
Los tres stacks ya existían (backend/spring, backend/dotnet, frontend/angular), pero tenían huecos reales alrededor. Added: - Estándares de C# en el agente coder. 'Estándares por lenguaje' cubría TypeScript, Python, Go, Rust, Solidity, PHP, Java y Dart, pero no C#, pese a existir un stack backend/dotnet completo y a que la regla de nombres ya lo mencionaba. Un proyecto .NET recibía el overlay del stack pero ninguna guía de lenguaje. - Overlays de Spring (25→40), .NET (26→44) y Angular (26→47) profundizados con concurrencia, resiliencia, caché, observabilidad y calidad de proyecto. Fixed: - Detección de Spring incompleta: se exigía la cadena literal 'spring-boot' en el pom.xml, así que un proyecto que solo declara org.springframework (BOM o Spring Framework sin Boot) no se detectaba; y los settings.gradle(.kts) no se miraban. Los casos de build.gradle(.kts) sí funcionaban ya y quedan cubiertos como guardas de regresión. - Un proyecto Java sin Spring quedaba en un callejón sin salida: la detección devolvía null sin explicar nada. Ahora se imprime qué se vio y se aclara que el overlay de Java del kit es Spring Boot, avisando de que para Quarkus, Micronaut o Jakarta EE puro no encaja. Tests: 51 (10 nuevos de detección).
Añadido: la detección ya no exige que el manifiesto esté en la raízInstalar el kit en un proyecto C# real destapó un fallo mayor que los de este PR: la detección solo miraba la raíz del repo. Con Cómo quedaLas reglas se factorizan a La raíz mantiene prioridad absoluta, así que ningún proyecto que ya se detectaba cambia de resultado — hay un test que lo fija.
Auditable, no un acto de feEsa segunda línea responde justo la duda que se plantea al instalar en la raíz teniendo el proyecto en un subdirectorio. Verificación
Costo: 156 ms en un repo hostil de 422 directorios sin nada detectable — y solo se paga cuando la raíz no resuelve. Tests: 51 → 56. |
Pediste soporte para Java, C# y Angular. Los tres stacks ya existían —
backend/spring,backend/dotnetyfrontend/angular, con detección funcionando — pero al revisarlos encontré huecos reales alrededor, y eso es lo que cierra este PR.Probablemente no aparecían porque hasta el PR #15 el árbol del README listaba
backend/{_common,nestjs,fastapi,php}y se comíaspringydotnet.C# no tenía estándares de lenguaje
coder.mdcubría TypeScript, Python, Go, Rust, Solidity, PHP, Java y Dart. C# no, pese a existir un stackbackend/dotnetentero y a que la propia regla de nombres del agente ya lo mencionaba (camelCase(TS/JS/Java/C#/Dart)). Un proyecto .NET recibía el overlay del stack pero ninguna guía de lenguaje.Se añade su sección —nullable reference types y el
!como lo que es,record/sealed,asyncsin.Result/async void,CancellationTokenpropagado, excepciones específicas, analyzers como error— y se incluye C# en la lista de lenguajes del agente.La detección de Spring se dejaba casos
Se exigía la cadena literal
spring-booten elpom.xml. Lo verifiqué ejecutando el predicado viejo caso por caso:pom.xmlconspring-boot-starterpom.xmlsolo conorg.springframework(BOM, Framework sin Boot)build.gradle.ktscon el pluginbuild.gradleconio.spring.dependency-managementsettings.gradle(.kts)Los dos que ya funcionaban quedan como guardas de regresión, etiquetados como tales en el test — no los presento como arreglos.
Java sin Spring ya no es un callejón sin salida
La detección devolvía
nullsin explicar nada y, con--yes, el instalador salía con código 1 a secas. Ahora imprime qué vio:Misma pista para Go, Rust y para un
package.jsonsin framework reconocido. Deliberadamente no fuerzo un proyecto Quarkus al overlay de Spring: le daría consejos que no aplican. Soporte real de Quarkus/Micronaut son stacks nuevos, que es trabajo aparte.Overlays más profundos
backend/spring@Asynccon executor explícito, Resilience4j,@Cacheablecon clave y TTL, Actuator + Micrometer,readOnlyen lecturas, la trampa del proxy de@Transactionalen llamadas internas, slices de test frente a@SpringBootTestbackend/dotnetCancellationTokenpropagado,IHttpClientFactorycon typed clients y resiliencia,HybridCache, OpenTelemetry, health checks,MapGroupcon filtros, la captura deScopeddesdeSingleton,Nullable/TreatWarningsAsErrors,ConfigureTestServicesfrontend/angular@defer,computedfrente aeffect,linkedSignal, rutas lazy con guards funcionales ywithComponentInputBinding, interceptores funcionales, formularios reactivos tipados,NgOptimizedImage, accesibilidad, presupuestos de bundleSobre las APIs
resource/rxResource/httpResourcede Angular dejo escrito que confirmes su nivel de estabilidad contra la versión exacta del proyecto, en vez de afirmarlo yo: su estado ha ido cambiando entre versiones.Test plan
node --test— 51 tests, 10 nuevos de detección: las cinco variantes de Spring, Java sin Spring (no se marca como Spring, explica por qué y sale con código 1),.csproj,angular.json,@angular/core, y las pistas de Go/Rustnode scripts/validate.cjs— 49 comprobaciones (incluye el check es-MX sobre los overlays)